Can you provide instructions on how we can test this?

Can you provide instructions on how we can test this?

Basically on my Linux install I followed the instructions from https://github.com/mstorsjo/msvc-wine, then added the install folder/bin/x64 to my PATH, set both CC and CXX environment variables to cl and then ran vcpkg install zlib --triplet=x64-windows. With this simple patch this ran successfully and built zlib just fine.

Stupid question: Does removing:

#if !defined(WIN32)
        Checks::msg_exit_with_error(VCPKG_LINE_INFO, msgErrorVcvarsUnsupported, msg::triplet = prebuildinfo.triplet);
#else

fix it rather than adding this? (I'm sorry to be asking lots of questions about this; I'm just nervous about adding funny ifdefs for things I can't check)

Stupid question: Does removing:

#if !defined(WIN32)
        Checks::msg_exit_with_error(VCPKG_LINE_INFO, msgErrorVcvarsUnsupported, msg::triplet = prebuildinfo.triplet);
#else

fix it rather than adding this?

Sorry for the late reply, but no as far as I can tell it doesn't because it tries to find Visual Studio toolsets (it actually calls functions that are not even compiled outside of Windows) and on this setup there really isn't a proper Visual Studio toolset anyways.

I'm sorry to be asking lots of questions about this; I'm just nervous about adding funny ifdefs for things I can't check

Yeah no problem, if you decide that this is too funny of a setup / quirk to be supported and reject this PR that would also be understandable, not many people will try to use something like this anyways.

Yeah no problem, if you decide that this is too funny of a setup / quirk to be supported and reject this PR that would also be understandable, not many people will try to use something like this anyways.

No, I don't want to outright reject, I just want to make sure I understand since this isn't a configuration I understand. I'm also trying to "probe" because this specific change is "strange" (why should non-Windows but 'using vcvars' take the 'no vcvars' return?). And upon seeing the terminate immediately below the edited code triggering on the same condition, that seems an obvious reason why.

It looks like you actually want vcvars used here. In that case we should probably return a Toolset that claims to do this rather than just giving up and falling to external toolset / PATH?

    struct Toolset
    {
        Path visual_studio_root_path;
        Path vcvarsall;
        std::vector<std::string> vcvarsall_options;
        ZStringView version;
        std::string full_version;
        std::vector<ToolsetArchOption> supported_architectures;
    };

Seems like we should be returning something with those values filled out for this setup rather than the dummy values that appear to fall back to PATH....

We also have other comments that are wrong after this change, such as:

#if !defined(WIN32)
        // pre_build_info.using_vcvars() should always be false on non-Win32 hosts.
        // If it was true, we should have failed earlier while selecting a Toolset
        (void)toolset;
        Checks::unreachable(VCPKG_LINE_INFO);
#else

in make_build_env_cmd.

I'm not sure filling out the toolset values it going to be possible as on my setup I just have cl, link, lib, etc. in PATH, while my setup does have the vcvars scripts installed I make no use of them. I think it might just be better to leave this unmerged as I really isn't practical anyways.